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@ Verfahren zur kryptographischen Sicherung der rechnergestutzten digitalen Kommunikation zwischen einem 
Programm und mindestens einer Benutzereinheit 

(57) Da bei vielen Client-Server- Fenster-Systemen die Syste- 
me nur in Objaktcode und nicht in Quellcode vorliegen, 1st 
eine Sicherheitserweiterung nur schwer bzw. gar nicht 
moglich. 

Bei dem erfindungsgemaBen Verfahren werden die schon in 
Transportprotokoliformat (TP) codierten Anforderungen (A) 
bzw. Nachrichten (B) noch einmal in der Transportprotokoll- 
schicht (TP) decodiert, und dann in einer Sicherheitsschicht 
(SL) beliebigen kryptographischen Verfahren unterzogen. 
Danach werden sie wieder in der Trans portprotokollschicht 
(TP) codiert und einem Programm (P) oder mindestens einer 
Benutzereinheit (XS) ubertragen. 

Damit ist eine Sicherheitserweiterung, beispielsweise hin- 
sichtlich der Verschlusseiungsdaten, der Autentikation oder 
■ auch der Zugriffskontrolle, erreicht. 
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Die Erfindung betrifft ein Verfahren zur kryptogra- 
phischen Sicherung der Kommunikation in sogenannten 
Client-Server-Fenster-Systemen mit einer offenen 
Netzschnittstelle. Ein Beispiel solcher Client-Server* 
Fenster-Systeme ist beschrieben in [1]. 

Durch eine zusatzliche Verwendung einer sogenann- 
ten Application Sharing Komponente, die dazu verwen- 
det wird, Anforderungen von Benutzereinheiten an das 
Programm zu multiplexen und Nachrichten von dem 
Programm, zum Beispiel Ereignismeldungen, Antwor- 
ten oder Fehlermeldungen, fur die Benutzereinheiten zu 
demultiplexer wird die gemeinsame Nutzung einer 
Standard-Ein-Benutzer-Anwendung (Standard Single 
User Application) zwischen verschiedenen heterogenen 
Umgebungen, die sich an unterschiedlichen Orten befin- 
den konnen, erreicht 

Diese gemeinsame Bearbeitung eines Programms 
wird als Application Sharing bezeichnet 

Um jedoch auch eine verlaBliche Kommunikation 
vertraulicher Daten zu erreichen, muB das in [1] be- 
schriebene Client-Server-Fenster-System um krypto- 
graphische Merkmale erweitert werden. 

Dies ist von besonderer Bedeutung bei unterneh- 
mensiibergreifender Kommunikation. Dies bedeutet bei 
einer Kommunikation zwischen Rechnern, bei denen 
sich ein Rechner im prinzipiell abgesicherten vertrau- 
enswiirdigen sogenannten Corporate Network eines 
Unternehmens befindet, und anderen Rechnern, die sich 
in einer gemeinsamen synchronen verteilten Arbeitsum- 
gebung mehrerer vernetzter Rechner, in einem soge- 
nannten Computer System Cooperated Work-System 
(CSCW-Systemen), welches Application Sharing reali- 
siert, befindet, nur iiber einen unsicheren Kanal erreicht 
werden kann, wodurch eine sichere Kommunikation 
nicht mehr gewahrleistet ist 

Solche CSCW-Systeme basieren auf der Moglichkeit, 
eine Standard-Ein-Benutzer-Anwendung (Standard Sin- 
gle User Application) gemeinsam mit anderen Benut- 
zern zu einem Zeitpunkt zu bearbeiten. 

Die zwischen den Rechnern ausgetauschte Informa- 
tion kann von besonderer Bedeutung sein, beispielswei- 
se kann es sich um vertrauliche Geschaftsinformation 
handeln, um Designspezifikationen, Finanztransaktio- 
nen oder um medizinische Daten, die iiber den unsiche- 
ren Kanal ausgetauscht werden. 

Aus diesem Grund ist es notwendig auch fur diese 
Transaktionen von Anwendungsdaten eine gewisse Si- 
cherheit zu gewahrleisten. 

Bei vielen kommerziellen Systemen, die auf dem in [1] 
beschriebenen Client-Server-Fenster-System beruhen, 
ist eine direkte Integration kryptographischer Merkma- 
le nicht moglich. 

Der Erfindung liegt somit das Problem zugrunde, ein 
Verfahren zur kryptographischen Sicherung der rech- 
nergestutzten digitalen Kommunikation zwischen ei- 
nem Programm und mindestens einer Benutzereinheit, 
anzugebea 

Das Problem wird durch das Verfahren gemaB Pa- 
tentanspruch 1, das Verfahren gemaB Patentanspruch 4, 
das Verfahren gemaB Patentanspruch 7 sowie das Ver- 
fahren gemaB Patentanspruch 8 geldst 

Bei dem Verfahren gemaB Patentanspruch 1 wird von 
dem Programm eine Nachricht gebildet, die fur ein 
Transportprotokoll codiert wird Direkt nach der Codie- 
rung wird unter Verwendung des Transportprotokolls 
die codierte Nachricht wieder decodiert und die deco- 



dierte Nachricht einem kryptographischen Verfahren 
unterzogen. Danach wird die Anforderung wiederum 
mit dem Transportprotokoll codiert und an mindestens 
eine Benutzereinheit ubertragen. Hierbei konnen sich 
5 das Programm und die Benutzereinheit auf einem oder 
auch auf verschiedenen Rechnern befinden. 

Bei dem Verfahren gemaB Patentanspruch 4 werden 
prinzipiell dieselben Schritte ausgefuhrt, mit dem Un- 
terschied, daB diesmal eine Anforderung in einer Benut- 
io zereinheit gebildet wird und dort auch die im vorigen 
beschriebenen weiteren Schritte durchgefuhrt werden. 
Zum SchluB des Verfahrens wird in diesem Fall die co- 
dierte kryptographische verarbeitete Anforderung zu 
dem Programm ubertragen. 
15 Bei dem Verfahren gemaB Patentanspruch 7 wird von 
der Situation ausgegangen, daB auf der Seite des Pro- 
gramms eine Erweiterung des Client-Server-Fenster- 
Systems durch Sicherheitsmechanismen unterschied- 
lichster Art, die im weiteren beschrieben werden, mog- 
20 Hch ist Fur diesen Fall werden die im vorigen beschrie- 
benen Verfahrensschritte ausgehend von der Bildung 
einer Nachricht in dem Programm nur nach Empfang 
der kryptographisch in der eingefugten Sicherheits- 
schicht auf der Seite des Programms bearbeiteten An- 
25 forderungen in einer der Benutzereinheiten durchge- 
fuhrt Dort werden also die inversen kryptographischen 
Verfahren zur Bearbeitung der Nachrichten durchge- 
fuhrt, wobei dieser Verfahrensschritt durch eine zuvor 
erfolgte Decodierung mit dem Transportprotokoll und 
30 eine nachfolgende Codierung mit dem Transportproto- 
koll charakterisiert ist. 

Das Verfahren gemaB Patentanspruch 8 weist prinzi- 
piell die gleichen Verfahrensschritte auf wie das Verfah- 
ren gemaB Patentanspruch 7 mit dem Unterschied, daB 
35 hierbei eine Anforderung von einer Benutzereinheit ge- 
bildet wird und an das Programm ubertragen wird. Die 
Stellen, an denen die einzelnen Verfahrensschritte ab- 
laufen, und die Stellen, an denen die Verfahrensschritte 
des Patentanspruchs 7 ausgefuhrt werden, sind in die- 
40 sem Fall einfach vertauscht 

Vorteilhafte Weiterbildungen der erfindungsgema- 
Ben Verfahren ergeben sich aus den abhangigen An- 
spruchen. 

Es ist vorteilhaft, als kryptographische Bearbeitung 
45 zumindest eine Verschlusselung der Anforderung vor- 
zusehert Damit wird die Vertraulichkeit der ausge- 
tauschten Daten gewahrleistet 

Weiterhin ist es vorteilhaft, als kryptographische Be- 
arbeitung der Anforderung Integritats- und Authentika- 
50 tionsmechanismen vorzusehen, wodurch dann jeweils 
gewahrleistet ist, daB die empfangene Nachricht tat- 
sachlich von dem Absender stammt, der auch in der 
Nachricht als Absender angegeben ist 
In einer Weiterbildung der erfindungsgemaBen Ver- 
55 f ahren ist es auBerdem vorteilhaft, als kryptographische 
Verfahren Zugriffskontrollmechanismen zu realisieren, 
um somit sicherzustellen, daB wirklich nur diejenigen 
Anforderungen auch durchgefuhrt werden, die auch die 
Berechtigung zur Durchfuhrung aufweise. . 
60 Ferner ist es vorteilhaft vor Beginn de\ Verfahrens in 
einer Initialisierungsphase beispielsweist aie kryptogra- 
phischen Schlussel, die zur Realisierung der einzelnen 
kryptographischen Verfahren eingesetzt werden, auszu- 
tauschen zwischen dem Programm und der mindestens 
65 einen Benutzereinheit 

Eine vorteilhafte Verwendung der Verfahren findet 
sich beim Datenaustausch zwischen Kommunikations- 
partnern, die uber die Grenzen eine Coporate Net- 



works, welches durch kryptographische Verfahren in 
sich gesichert ist, uber einen unsicheren Kanai in einem 
sogenannten FirewalL 

Durch eine solche Verwendung ist es nicht mehr wie 
bisher n6tig f bei einer vorgesehenen Kommunikation 5 
Qber Coporate Network-Grenzen hinweg den fur die 
Kommunikation zu verwendenden Rechner von dem 
gesamten Netz des Coporate Networks zu entkoppeln, 
urn somit nicht das gesamte Coporate Network zu ge- 
fahrden bei moglichen Angriffen Qber den unsicheren to 
Kommunikationskanal. 

In den Figuren sind einige Ausfuhrungsbeispiele dar- 
gestellt, die im folgenden nSher erlautert werden. 

Es zeigen 

Fig. I das allgemeine Prinzip eines Client-Server- 15 
Fenster-Systems; 

Fig. 2 das allgemeine Prinzip eines Client-Server- 
Fenster-Systems in einer "Mehrbenutzer-Umgebung"; 

Fig. 3 eine Anordnung, die die Mehrbenutzer-Umge- 
bung detaillierter beschreibt; 20 

Fig. 4 ein prinzipielles Blockschaltbild, in dem das 
Einfugen einer Sicherheitsschicht zwischen Client-Sur- 
fer-Fenstersystem und dem Transportprotokoli be- 
schrieben ist; 

Fig. 5 eine Anordnung, in der prinzipiell dargestellt 25 
ist, wie das erfindungsgemafle Verfahren in einem Fire- 
wall zur Kommunikationssicherung Uber Coporate Net- 
work-Grenzen hinweg verwendet werden kann; 

Fig. 6 ein Ablaufdiagramm, in dem die Verfahrens- 
schritte des Verfahrens gemaB Patentanspruch 1 darge- 30 
stellt sind; 

Fig. 7 ein Ablaufdiagramm, in dem die Schritte des 
Verfahrens gemaB Patentanspruch 2 dargestellt sind; 

Fig. 8 ein Blockdiagramm, in dem die einzelneh Mog- 
lichkeiten zur Realisierung der sicherheitsspezifischen 35 
Bearbeitung der Anforderung bzw. der inversen sicher- 
heitsspezifischen Bearbeitung der Anforderung be- 
schrieben ist 

Fig. 9 ein Ablaufdiagramm, in dem die einzelnen Ver- 
fahrensschritte des Verfahrens gemaB Patentanspruch 4 40 
dargestellt sind; 

Fig. 10 ein Ablaufdiagramm, in dem die Schritte des 
Verfahrens gemaB Patentanspruch 5 dargestellt sind; 

Fig. 1 1 ein Ablaufdiagramm, in dem die Schritte des 
Verfahrens gemaB Patentanspruch 7 dargestellt sind; 45 

Fig. 12 ein Ablaufdiagramm, in dem die Schritte des 
Verfahrens gemaB Patentanspruch 8 dargestellt sind; 

Fig. 13 ein Blockschaltbild, in dem die einzelnen zur 
Durchfuhrung des Verfahrens gemaB Patentanspruch 1 
benotigten Komponenten und der Nachrichtenaus- 50 
tausch beschrieben ist; 

Fig. 14 ein Blockschaltbild, in dem die einzelnen zur 
Durchfiihrung des Verfahrens gemaB Patentanspruch 4 
benotigten Komponenten und der Nachrichtenaus- 
tausch beschrieben ist; 55 

Fig. 15 ein Blockschaltbild, in dem die einzelnen zur 
Durchfiihrung des Verfahrens gemaB Patentanspruch 2 
benotigten Komponenten und der Nachrichtenaus- 
tausch beschrieben ist; 

Fig. 16 ein Blockschaltbild, in dem die einzelnen zur 6 o 
Durchfiihrung des Verfahrens gemaB Patentanspruch 5 
benotigten Komponenten und der Nachrichtenaus- 
tausch beschrieben ist; 

Fig. 17 ein Blockschaltbild, in dem die einzelnen zur 
Durchfuhrung des Verfahrens gemaB Patentanspruch 7 65 
benotigten Komponenten und der Nachrichtenaus- 
tausch beschrieben ist; 

Fig. 18 ein Blockschaltbild, in dem die einzelnen zur 



Durchfuhrung des Verfahrens gemaB Patentanspruch 8 
benotigten Komponenten und der Nachrichtenaus- 
tausch beschrieben ist. 

Anhand der Fig. 1 bis 18 wird die Erfindung weiter 
erlautert 

In Fig. 1 ist eine Benutzerumgebung dargestellt, die 
beispielsweise bei einem Client-Server-Fenster-System, 
welches in [1] beschrieben ist, auftritt 

Diese Anordnung weist mindestens folgende Kompo- 
nenten auf: 

— eine Benutzereinheit XS, im weiteren als auch 
Server XS bezeichnet, die wiederum folgende 
Komponenten aufweist: 

— mindestens eine Treibereinheit DD, die eine 
Kopplung zwischen weiteren Peripheriekompo- 
nenten mit einem im weiteren beschriebenen 
Klienten XC ermoglicht, 

— eine Bildschirmeinheit BS, 

— eineTastaturTA, 

— eine Maus MA, 

— den Klienten XQder mindestens folgende Kom- 
ponenten aufweist: 

— eine Menge von Bibliotheksroutinen XLsowie 

— eine Anwendung ANW. 

Die Bildschirmeinheit BS, die Tastatur TA, die Maus 
MA sowie eventuell auBerdem vorhandene weitere Pe- 
ripherieeinheiten bilden die im vorigen beschriebenen 
Peripheriekomponenten, die uber die entsprechenden 
Treibereinheiten DD mit dem Klienten XC gekoppelt 
sind. 

Die Menge der Bibliotheksroutinen XL des Klienten 
XC bildet die Schnittstelle zwischen der Anwendung 
ANW, beispielsweise einem Textverarbeitungspro- 
gramm oder auch einem Tabellenkalkulationspro- 
gramm oder alien anderen bekannten Anwendungen 
ANW, und der Benutzereinheit XS. 

Zusammen bilden die Bibliotheksroutinen XL sowie 
die Anwendung ANW ein Programm P. 

Auch wenn in diesem Ausfiihrungsbeispiel nur jeweils 
eine Anwendung ANW bzw. ein Programm P beschrie- 
ben wird, konnen selbstverstandlich mehrere Anwen- 
dungen ANW und damit mehrere Klienten XC auf ei- 
ner, diese Anwendung ANW ausfiihrenden Rechnerein- 
heit zur Verf ugung gestellt werden. 

Diese in Fig. 1 dargestellte Anordnung ist also nur ein 
sehr einfaches, prinzipielles Beispiel fur den Ablauf der 
Kommunikation eines Klienten XC mit dem Server XS, 
wie sie unter dem bekannten, in [1] beschriebenen 
Client-Server-Fenster-System durchgefiihrt wird. 

Von dem Server XS wird eine Anforderung A an den 
Klienten XC gesendet Dadurch werden in dem Klien- 
ten XC Aktionen, beispielsweise in der Anwendung 
ANW, angestoBen. 

Die Anforderung A kann zum Beispiel eine Eingabe 
auf der Tastatur TA sein, die durch die Treibereinheiten 
DD in die Anforderung A "ubersetzt" und an den Klien- 
ten XC gesendet wird. 

Die Anwendung ANW, beispielsweise ein Textbear- 
beitungsprogramm oder ein Kalkulationsprogramm, ein 
Zeichenprogramm und ahnliche Programme, kann nun 
die Eingabe akzeptieren und beispielsweise als einen 
neuen Buchstaben in der Textdatei aufnehmen. 

Damit diese Anderung in der Textdatei auch auf dem 
Bildschirm BS dargestellt werden kann, wird in einer 
Antwort B in diesem Fail beispielsweise eine Darstel- 
lungsnachricht an die Bildschirmeinheit BS gesendet, 



BNSOOCID: <OE 19548387C1> 



DE 195 

5 

mit der eine Anderung in der Bildschirmdarstellung an- 
gefordert wird. 

Ein Nachteil vieler kommerzieller Systeme, die nach 
diesem Prinzip arbeiten, liegt vor allem darin, daB eine 
direkte Integration bendtigter Sicherheitsmechanismen 
in das Client-Server- Fenster-System oftmals nicht mog- 
lich ist. 

Hierzu ware namlich ein direkter Eingriff in die 
Schnittstelle zwischen den Bibliotheksroutinen XL und 
den Transportprotokollen notig. Diese sind eben oft- 
mals dem Benutzer nicht zugSnglich. 

In Fig. 6 ist ein Ablaufdiagramm mit einzelnen Ver- 
fahrensschritten des erfindungsgemaBen Verfahrens ge- 
maB Patentanspruch 1 dargestellt. Die zur Durchfuh- 
rung dieses Verfahrens notige Anordnung ist in Fig. 13 
beschrieben. 

Von dem Programm P wird in einem ersten Schritt 
601 die Nachricht B gebildet 

In einer Transportprotokollschicht TP wird aus der 
Nachricht B eine neue Nachricht gebildet, in dem die 
Nachricht B in das Transportprotokollformat "eingebet- 
tet" also codiert wird 602, CB. 

Eine Obersicht iiber verschiedene Transportproto- 
kolle ist in [2] zu finden. Die erfindungsgemaBen Verfah- 
ren sind unabhangig von dem speziell jeweils verwende- 
ten Transportprotokoll. 

Entweder auf derselben Rechnereinheit, auf der das 
Programm P lauft, oder auf einer gesondert vorgesehe- 
nen ersten Sicherungscomputereinheit SCI, die iiber ei- 
nen sicheren Kanal mit dem Rechner gekoppeh ist, wird 
in der dort vorgesehenen Transportprotokollschicht TP 
die codierte Nachricht CB decodiert 603, DB. 

Die decodierte Nachricht DB wird nun einer Sicher- 
heitsschicht SL zugefuhrt, in der sie unterschiedlichen, 
beliebig vorgegebenen kryptographischen Verfahren 
unterzogen wird 604. 

Eine durch die kryptographische Bearbeitung gebil- 
dete kryptographisch bearbeitete Nachricht VB wird 
nun wiederum in der Transportprotokollschicht TP co- 
diert 605, wodurch eine codierte kryptographisch verar- 
beitete Nachrichtung CVB gebildet wird. 

Die codierte kryptographisch verarbeitete Nachricht 
CVB wird in einem letzten Schritt 606 an die Benutzer- 
einheit XS, also an den Server ubertragen. 

Der prinzipiell umgekehrt gelagerte Fall fur die An- 
forderung A aus Fig. 1 ist in Fig. 9 in Form eines Ablauf- 
diagramms und in Fig. 14 in Form eines Blockdia- 
gramms fur die Anordnung, die zur Durchfiihrung des 
Verfahrens benotigt wird, dargestellt 

In diesem Fall wird die Anforderung A von der Benut- 
zereinheit XS gebildet 901. 

Die Anforderung A wird der Transportprotokoll- 
schicht TP zugefuhrt und dort in das jeweils verwendete 
Transportprotokollformat eingebettet 902. Eine hieraus 
resultierende codierte Anforderung CA wird nunmehr 
entweder in der Benutzereinheit XS selbst oder in einer 
gesondert vorgesehenen zweiten Sicherungscompute- 
reinheit SC2, die fiber einen sicheren Kanal mit der 
Benutzereinheit XS gekoppeh ist, in der Transportpro- 
tokollschicht TP "ausgepackt", also decodiert 903, wo- 
durch eine decodierte Anforderung DA gebildet wird. 

In der Sicherheitsschicht SL wird die ihr zugefuhrte 
decodierte Anforderung DA nunmehr den vorgesehe- 
nen kryptographischen Verfahren, die im weiteren be- 
schrieben werden, unterzogen 904. Daraus resultiert ei- 
ne kryptographisch bearbeitete Anforderung VA. 

Die kryptographisch bearbeitete Anforderung VA 
wird wiederum der Transportprotokollschicht TP zuge- 
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fuhrt 905 und dort codiert, wodurch eine codierte kryp- 
tographisch bearbeitete Anforderung CVA gebildet 
wird. Die codierte kryptographisch bearbeitete Anfor- 
derung CVA wird in einem letzten Schritt 906 an das 
5 Programm P, also an den Klienten XC ubertragen. 

Eine Weiterbildung des Verfahrens gemaB Patentan- 
spruch 1 ist in Fig. 7 in Form eines Ablaufdiagramms, 
sowie die zur Durchfiihrung dieses Verfahrens notwen- 
dige Anordnung in Fig. 16 dargestellt. 

io Nachdem die in Fig. 6 dargestellten Verfahrensschrit- 
te zur letztendlich gebildeten codierten kryptogra- 
phisch verarbeiteten Nachricht CVB, die an die Benut- 
zereinheit XS ubertragen wird, durchgefuhrt wurden, 
wird die codierte kryptographisch bearbeitete Nach- 

15 richt CVB von der mindestens einen Benutzereinheit XS 
oder von der zweiten Sicherungscomputereinheit SC2 
empfangen 701. 

Unter Verwendung des zur Codierung verwendeten 
Transportprotokolls wird die codierte kryptographisch 

20 bearbeitete Nachricht CVB in der Transportprotokoll- 
schicht TP der Benutzereinheit oder der zweiten Siche- 
rungscomputereinheit SC2 "ausgepackt", also decodiert 
702. 

Damit wird eine decodierte kryptographisch verar- 

25 beitete Nachricht DVB gebildet, die nun der Siche- 
rungsschicht SL,die auch auf der Seite der Benutzerein- 
heit XS bzw. der zweiten Sicherungscomputereinheit 
SC2 vorgesehen ist, zugefuhrt In der Sicherheitsschicht 
SL wird die decodierte kryptographisch bearbeitete 

30 Nachricht DVB den jeweils inversen kryptographischen 
Verfahren unterzogen 703. Invers bedeutet in diesem 
Zusammenhang invers zu den kryptographischen Ver- 
fahren, die in der Sicherheitsschicht des Klienten XC 
bzw. der ersten Sicherungscomputereinheit SCI auf die 

35 decodierte Nachricht DB angewendet wurden. 

Das Ergebnis dieser kryptographischen Bearbeitung 
ist eine invers kryptographisch bearbeitete Nachricht 
DEB, die nun wiederum der Transportprotokollschicht 
TP zugefuhrt wird, wo sie auch wieder codiert wird 704. 

40 Die daraus entstandene codierte invers kryptogra- 
phisch bearbeitete Nachricht CEB wird wiederum der 
Transportprotokollschicht TP zugefuhrt und dort deco- 
diert 705. 

Die resultierende Nachricht wird nunmehr dem ei- 

45 gentlichen Server XS, also der Benutzereinheit XS, zu- 
gefuhrt und dort weiterverarbeitet Es ist selbstver- 
standlich in einer Variante des Verfahrens auch mdglich, 
direkt die invers kryptographisch bearbeitete Nachricht 
DEB weiter zu verarbeiten. 

so Die prinzipiell gleiche Weiterbildung des Verfahrens 
gemaB Patentanspruch 4 wie die im vorigen beschriebe- 
ne Weiterbildung fur das Verfahren gemaB Patentan- 
spruch 1 ist in Fig. 10 dargestellt sowie die zur Durch- 
fiihrung des Verfahrens gemaB Patentanspruch 5 beno- 

^5 tigte Anordnung in Fig. 1 7. 

Bei dieser Weiterbildung wird wiederum davon aus- 
gegangen, daB die in Fig. 9 beschriebenen Verfahrens- 
schritte bis zur Codierung der kryptographisch bearbei- 
teten Anforderung VA und deren Obertragung an das 

60 Programm P durchgefuhrt wurden. 

Die ubertragene codierte kryptographisch bearbeite- 
te Anforderung CVA wird von dem Programm P oder 
von der ersten Sicherungscomputereinheit SCI empfan- 
gen 1001. 

65 In einem weiteren Schritt 1002 wird unter Verwen- 
dung des Transportprotokolls wiederum die codierte 
kryptographisch bearbeitete Anforderung CVA "ausge- 
packt", also decodiert in der Transportprotokollschicht 



TP. 

Weiter wird die daraus resultierte decodierte krypto- 
graphisch bearbeitete Anforderung DVA in der Sicher- 
heitsschicht SL, der sie zugefuhrt wurde, der zu dem 
eingesetzten kryptographischen Verfahren inversen 
kryptographischen Verarbeitung unterzogen 1003. 

Die resultierende invers kryptographisch bearbeitete 
Anforderung DEA wird wiederum in der Transportpro- 
tokollschichtTPcx>diert 1004. 

AnschlieBend wird sie in der Transportprotokoll- 
schicht TP wiederum decodiert 1005 und dem Pro- 
gramm P zugefuhrt Dort wird die eigentliche Anforde- 
rung A weiterverarbeitet 

Wiederum ist es ebenso mdglich, direkt die decodier- 
te invers kryptographisch bearbeitete Anforderung 
DEA dem Programm P zuzufuhren und dort weiterzu- 
verarbeiten. 

In Fig. 1 1 ist ein weiteres Verfahren, das ebenso auf 
der gemeinsamen erfinderischen Idee der im vorigen 
beschriebenen Verfahren basiert, beschrieben. 

Hierbei wird jedoch vorausgesetzt, daB es mdgiich ist, 
direkt eine Sicherheitsschicht SL zwischen dem Klien- 
*' ten XC und der Transportprotokollschicht TP einzufu- 
gen. Hieraus ergibt sich nunmehr nicht mehr die Not- 
wendigkeit auf der Seite des KJienten XC die Transport- 
protokollschicht TP z weimal zu "durchlauf en". 

Dies ist in der Anordnung von Fig. 1 7 dargestellt 

Hierbei wird wiederum von dem Programm P die 
Nachricht B gebildet 1101. Die Nachricht B wird jedoch 
diesmal direkt in der Sicherheitsschicht S- einen krypto- 
graphischen Verfahren unterzogen VB, 1 102. Die resul- 
tierende kryptographisch bearbeitete Nachricht VB 
wird der Transportprotokollschicht TP zugefuhrt, wo 
sie codiert wird 1 103. 

Die codierte kryptographisch bearbeitete Nachricht 
CVB wird an die Benutzereinheit XS ubertragen 1104, 
dort von der Benutzereinheit XS oder der zweiten Si- 
cherungscomputereinheit SC2 empfangen 1105, in der 
dort vorgesehenen Transportprotokollschicht TP deco- 
diert zu der decodierten kryptographisch bearbeiteten 
Nachricht DVB 1106. 

Diese wird der Sicherheitsschicht SL zugefuhrt und 
dort dem bzw. den inversen kryptographischen Verfah- 
ren unterzogen 1107. 

In zwei letzten Schritten wird die invers kryptogra- 
phisch bearbeitete Nachricht DEB in der Transportpro- 
tokollschicht TP wiederum codiert 1108 und in einem 
letzten Schritt decodiert 1 109. 

Die daraus resultierende Nachricht B wird dem Ser- 
ver XS zugefuhrt und weiter verarbeitet 

Die Sicherheitsschicht SL ist in Fig. 4 dargestellt fur 
den Fall, daB es mdglich ist, die Sicherheitsschicht SL 
zwischen die Transportschicht TP und die Bibliotheks- 
routinen XL einzufugen. 

Hierbei werden fur das spezielle Beispiel, das jedoch 
die Allgemeingtiltigkeit in keinster Weise einschrankt, 
ungesicherte read, write, readv, writev connect und ac- 
cept Nachrichten durch in der Sicherheitsschicht SL 
vorgesehene kryptographische Verfahren "abgesichert". 
Dies erfolgt durch Anwendung der vorgesehenen kryp- 
tographischen Verfahren auf die jeweilige Nachricht B 
bzw. Anforderung A. Die durch die Sicherheitsschicht 
SL "gesicherten w Nachrichten sind mit einem Stern * in 
Fig. 4 gekennzeichnet 

Die beschriebene kryptographische Sicherung der 
ICommunikation einer Anwendung mit einem Fenster- 
system uber ein Netz setzt einerseits den Austausch 
kryptographischer Schliissel voraus und beruht ande- 



rerseits auf einer wechselseitigen Authentikation der 
beiden Kommunikationspartner. 

Zu dieser Authentikation konnen asymmetrische, 
kryptographische Verfahren mitsamt Zertifikaten, die 
5 offentliche Schlussel enthalten, vorteilhaft eingesetzt 
werden. Durch eine geeignete Definition der Identitats- 
merkmale in dem Zertifikat ist es mdglich, Dienste wie 
Anwendungen oder Fensterdienstprogramme uber die 
reine Rechneradresse im Netz hinaus zu identifizieren 

io und zu authentisieren. Solche uber die Netzadresse hin- 
ausgehenden Identitatsmerkmale zur Qifferenzierung 
verschiedener Anwendungsprogramme eines Rechners 
konnen z. B. der Name des Dienstebesitzers auf einem 
Mehrbenutzersystem sein. 

15 Die wechseiseitige Authentikation und der Schlussel- 
austausch werden in einer Initialisierungsphase zum 
Aufbau der sicheren Verbindung realisiert. 

In einer Weiterbildung des erfindungsgemaBen Ver- 
fahrens ist es vorteilhaft, auf der Seite des Fenster- 

20 dienstprogrammes, also der Benutzereinheit XC eine 
Zugriffskontrolle auf Basis der authentifizierten Identi- 
tat des Programmes P durchzufiihren. Da die authentifi- 
zierte Identifikationsinformation iiber die Rechner- 
adresse des Programmes P hinausgehen kann, kann eine 

25 Zugriffskontrolle zwischen verschiedenen Programmes 
P eines Rechners unterscheiden und somit den Verbin- 
dungsaufbau steuern. 

Eine vorteilhafte Anwendung der beschriebenen Si- 
cherungsverfahren findet sich beim Austausch von An- 

30 wendungsdaten zwischen einem Programmes P und ei- 
nem Fensterdienstprogramm, also einer Benutzerein- 
heit XC, wobei zwischen beiden nur eine nicht vertrau- 
enswiirdige Netzverbindung geschaitet werden kann. 
Dieses Szenario ist von besonderer Bedeutung fur die 

35 oben beschriebenen CSCW-Systeme, die Application 
Sharing realisieren. Hierbei befinden sich die beteiligten 
Fensterdienstprogramme der Benutzereinheiten XC 
oftmals in verschiedenen Firmennetzen und kdnnen Da- 
ten mit der Anwendung bzw. der Application Sharing 

40 Komponente nur iiber offentliche Netze austauschen. 
Mit dem Betreiben des bekannten Fenstersystems 
sind erhebliche Sicherheitsprobleme verbunden, welche 
in [6J [7] beschrieben werden. Aufgrund des erheblichen 
Risikopotentials, welches mit dem aus [1] bekannten 

45 Fenstersystem verbunden ist, lassen es die Betreiber 
von Firmennetzen in der Regel nicht zu, daB solche 
Fensterdienstprogramme mit Anwendungen auBerhalb 
des Firmennetzes zusammenarbeiten. Dies dient dem 
Schutz firmeninterner Informationen und Datenbestan- 

50 de. Dieser Schutz wird durch sogenannte Firewalls am 
Netzubergang zwischen internem Netz und externen 
Netzen realisiert. Diese verhindern durch eine Filterung 
von Datenpaketen auf Transportsystemebene, daB ex- 
terne Anwendungsprogramme auf interne Fenster- 

55 dienstprogrammezugreifen, 

Diese ublichen Vorkehrungen verhindern aber die 
Nutzung synchroner CSCW-Systeme, die darauf beru- 
hen, daB Nutzer an unterschiedlichen Standorten und in 
verschiedenen Firmen gemeinsam durch ein synchrones 

eo CSCW-System kooperieren und gemeinsam mit An- 
wendungsprogrammen arbeiten. 

Auf Basis des beschriebenen Sicherungsverfahren fiir 
Anwendungsdaten laBt sich ein Programm fiir ein Fire- 
wall konstruieren, welches es ermoglicht, interne Fen- 

65 sterdienstprogramme auf sichere Weise mit externen 
Anwendungsprogrammen kommunizieren zu lassen: 

Dieses spezielle Programm beruht einerseits auf der 
beschriebenen Sicherheitserweiterung zum Schutz von 



BNS0OCID:<0E 19S48387C1 



DE 195 48 387 CI 



10 



Anwendungsdaten in Fenstersystemen und andererseits 
auf einer Durchschaltekomponente fur Anwendungsda- 
ten. Die Durchschaltekomponente kann direkt aus der 
Application Sharing Komponente ASC abgeleitet wer- 
den, da hierzu die Anforderung des Multiplexens und 5 
Demultiplexer entfallt 

Diese beiden Komponenten (Sicherheitsdienstpro- 
gramm und Durchschaltekomponente) bilden ein spe- 
zielles Firewall-Sicherheitsdienstprogramm durch wel- 
ches es moglich wird, von einem externen Anwendungs- 10 
programm eine spezifische Authentikation zu verlan- 
gen, sowie es einer Zugriffskontrolle zu unterziehen, 
bevor die Durchschaltekomponente die Verbindung zu 
dem intemen Fensterdienstprogramm herstellt und an- 
schlieBend die Verbindung durchstellt Der nachfolgen- 15 
de Datenaustausch zwischen dem externen Anwen- 
dungsprogramm und dem Firewall-Sicherheitsdienst- 
programm wird durch kryptographische Mechanismen 
geschutzt 

Durch das Betreiben von Paketfiltern im Firewall 20 
konnen externe Anwendungsprogramme gezwungen 
werden, zunachst die Verbindung zu dem beschriebenen 
Sicherheitsdienstprogramm aufzunehmen. 

Das entsprechende Verfahren unter Beriicksichti- 
gung des "Rollentauschs" zwischen Programm und Be- 25 
nutzereinheit XS, also fur die Anforderung A, ist in 
Fig. 12 sowie die zu deren Durchfiihrung benotigte An- 
ordnung in Fig, 18 dargestellt 

Hierbei wird naturlich angenommen, daB die Sicher- 
heitsschicht SL auf der Seite der Benutzereinheit XS 30 
zwischen die Benutzereinheit XS und die Transportpro- 
tokollschicht TP eingefugt werden kann. 

Unter dieser Annahme wird also von der Benutzer- 
einheit XS die Anforderung A gebildet 1201. Diese wird 
direkt in der Sicherheitsschicht SL dem kryptographi- 35 
schen Verfahren VA unterzogen 1202. 

Die kryptographisch bearbeitete Anforderung VA 
wird in der Transportprotokollschicht TP codiert 1203 
und im AnschluB daran wird die codierte kryptogra- 
phisch bearbeitete Anforderung CVA an das Programm 40 
Pubertragenl204. 

Dort wird sie von dem Programm P oder von der 
ersten Sicherungscomputereinheit SCI empfangen 
1205. In einer auch dort vorgesehenen Transportproto- 
kollschicht TP wird sie nunmehr decodiert zur decodier- 45 
ten kryptographisch bearbeiteten Anforderung DVA 
1206. 

In der Sicherheitsschicht SL der sie in einem weiteren 
Schritt zugefuhrt wird, wird die decodierte kryptogra- 
phische Anforderung dem inversen kryptographischen 50 
Verfahren unterzogen 1207. Die daraus resultierende 
invers kryptographisch bearbeitete Anforderung DEA 
wird in der Transportprotokollschicht TP wiederum 
"eingepackt", also codiert 1 208. 

Die codierte inverse kryptographische bearbeitete 55 
Anforderung CEA wird in der Transportprotokoll- 
schicht TP in einem weiteren Schritt wiederum deco- 
diert 1209 und die resultierende Anforderung A, die 
nunmehr kryptographisch "abgesichert" ist, wird dem 
Programm zugefuhrt und von dem Programm P weiter go 
verwendet 

Verschiedene Mdglichkeiten zur Realisierung der zu 
verwendenden kryptographischen Verfahren in der Si- 
cherheitsschicht SL sind in Fig. 8 dargestellt 

Zum einen ist es moglich, Verschlusselungsverf ahren 65 
81 in der Sicherheitsschicht SL anzuwenden. Damit wird 
eine Vertraulichkeit bzw. Integritat der ausgetauschten 
Nachrichten B bzw. Anforderungen A erreicht 



Ferner ist es vorgesehen, in der Sicherheitsschicht SL 
auch Authentikationsmechanismen 82 zu verwenden. 
Diese erlauben es, Identitatsangaben der Kommunika- 
tionspartner im Netz zu verifizieren. Diese Authentika- 
tionsmechanismen haben besondere Bedeutung in Zu- 
sammenhang zum Beispiel des Transport Control Pro- 
tocols (TCP), oder auch des User Datagramm Protocols 
(UDP), da diese keinerlei Authentikationsmechanismen 
fur Sender und Empfanger aufweisen. 

Auch die Realisierung von Zugriffskontrollmechanis- 
men 83, die auf den Authentikationsverfahren beruhen, 
bietet zusatzlichen Schutz des Zugangs zu dem Fenster- 
dienstprogramm in einem Client-Server-Fenster-Sy- 
stem. 



Die im vorherigen beschriebenen Verfahren konnen 
naturlich auch auf Mehrbenutzersysteme sehr vorteil- 
haft angewendet werden. 

Wie das [1] beschriebene Client-Server-Fenstersy- 
stem erweitert werden kann zu einem Mehrbenutzersy- 
stem ist beispielsweise beschrieben in [3J [4J [5J 

Die daraus resultierende Situation mit einer zusatzli- 
che Multiplexerkomponente ASC und mehreren Benut- 
zereinheiten XSi, wobei ein Index i jede Benutzereinheit 
XSi eindeutig identifiziert und eine naturliche Zahl im 
Bereich von 1 bis n ist, ist in Fig. 2 dargestellt 

Hierbei werden in bekannter Weise die Anforderun- 
gen Ai von den einzelnen Benutzereinheiten XSi zusam- 
mengefuhrt und die Nachricht B wird an die einzelnen 
Benutzereinheiten XSi als Kopien der Nachricht Bi ge- 
sendet 

Die erfindungsgemafien Verfahren werden in diesem 
Zusammenhang naturlich fur jede einzelne Verbindung 
zwischen dem Klienten XC und jeder Benutzereinheit 
XSi einzeln durchgefiihrt 

Detaillierter ist diese "Mehrbenutzer-Umgebung" 
noch in Fig. 3 dargestellt In dieser Realisierung entspre- 
chen die Anfordemngen Ai sogenannten Xrequests und 
die Nachrichten Bi den sogenannten Xreplies, Xevents, 
Xerrors. Die Anwendung ANW greift iiber Systemauf- 
ruf e SC auf Systemressourcen SR zu. 

In einer Weiterbildung des Verfahrens ist es vorteil- 
haft, zu Beginn des Verfahrens eine Initialisierungspha- 
se vorzusehen, in der beispielsweise ein Schliisselaus- 
tausch sowie eine beidseitige Authentikation zwischen 
einer Benutzereinheit XS der Benutzereinheiten XSi 
und dem Programm P durchgefiihrt wird. 

Hierbei sind dem Fachmann unterschiedlichste Ver- 
fahren zum Schliisselaustausch bekannt Als Beispiel ei- 
ner Initialisierungsphase,diein dem erfindungsgemaBen 
Verfahren eingesetzt werden kann, wird folgendes Vor- 
gehen vorgeschlagen. 

Das im folgende beschriebene Verfahren zum Schliis- 
selaustausch wird allgemein zwischen dem Klienten XC 
und einer Benutzereinheit XS durchgefiihrt. Die Multi- 
plexerkomponente ASC ist in diesem Zusammenhang 
als eine spezielle Komponente des Klienten XC zu be- 
trachten. 

Unter der Annahme, daB die Multiplexerkomponente 
ASC ein Anwendungszertifikat besitzt und die Benut- 
zereinheiten, also die Server XSi, jeweils ein Benutzer- 
zertifikat besitzen, die jeweils eindeutig den Benutzer- 
einheiten zugeordnet sind, wird dann von der Multiple- 
xerkomponente ASC eine erste Zufallszahl erzeugt 

Nachdem eine Transportverbindung zwischen der 
Multiplexerkomponente ASC und dem jeweiligen Ser- 
ver XSi aufgebaut wurde, wird von der Multiplexer- 
komponente ASC eine erste Verhandlungsnachricht an 
die Benutzereinheit gesendet, die mindestens folgende 



Komponenten aufweist: 

— das Programmzertifikat, 

— die erste Zufallszahl, 

— einen ersten Vorschlag fur ein im weiteren zu 
verwendende kryptographische Verfahren, und 

— eine digitale Unterschrift, die mindestens iiber 
die. erste Zufallszahl sowie den ersten Vorschlag 
gebildet wird. 

Die erste Verhandlungsnachricht wird von der jewei- 
ligen Benutzereinheit, also dem Server XSi, empfangen. 

Von der Benutzereinheit XSi wird das Programmzer- 
tifikat auf Konrektheit uberpruft 

Ferner wird die digitale Unterschrift uberpruft 

Falls die Oberprufung des Programmzertifikats und 
der digitalen Unterschrift ein positives Ergebnis liefert, 
wird in der Benutzereinheit XSi weiterhin uberpruft, ob 
die vorgeschlagenen kryptographischen Algorithmen 
die in der ersten Verhandlungsnachricht vorgeschlagen 
wurden, im weiteren zur Sicherung der Obertragung 
verwendet werden konnen. 

Wenn die Benutzereinheit XSi die vorgeschlagenen 
kryptographischen Algorithmen nicht unterstiitzen 
kann, wird von der Benutzereinheit, also dem Server 
XSi, ein zweiter Vorschlag in einer zweiten Vorschlags- 
nachricht gebildet und an die Multiplexerkomponente 
ASC gesendet Der zweite Vorschlag weist kryptogra- 
phische Verfahren auf, die die Benutzereinheit XSi un- 
terstiitzt Diese werden nunmehr der Multiplexerkom- 
ponente ASC als im weiteren Verfahren zu verwenden- 
de kryptographische Verfahren fur diese logische Ver- 
bindung zwischen der Multiplexerkomponente und der 
Benutzereinheit XSi vorgeschlagen. 

Die zweite Vorschlagsnachricht weist mindestens fol- 
gende Komponenten auf: 

— das Benutzerzertifikat des jeweiligen Servers 
XSi, 

— eine zweite Zufallszahl, die von der Benutzerein- 
heit XSi selbst erzeugt wurde, 

.— den zweiten Vorschlag, 

— eine digitale Unterschrift, die jeweils mindestens 
iiber die erste Zufallszahl, die zweite Zufallszahl 
sowie den zweiten Vorschlag gebildet werden. 

Die zweite Vorschlagsnachricht wird an die Multiple- 
xerkomponente ASC gesendet 

Fur den Fall, daB die in dem ersten Vorschlag angege- 
benen kryptographischen Algorithmen von dem Benut- 
zereinheit XSi unterstiitzt werden, wird von dem Benut- 
zereinheit XSi eine Bestatigungsnachricht gebildet und 
an die Multiplexerkomponente ASC gesendet 

Die Bestatigungsnachricht weist mindestens folgende 
Komponenten auf: 

— das Benutzerzertifikat, 

— die zweite Zufallszahl, 

— eine positive Best&tigung, und 

— eine digitale Unterschrift, die jeweils mindestens 
iiber die erste Zufallszahl, die zweite Zufallszahl, 
und die positive Bestatigung gebildet werden. 

Die Bestatigungsnachricht wird an die Multiplexer- 
komponente ASC gesendet 

Von der Multiplexerkomponente ASC wird die Ver- 
handlungsnachricht oder die Bestatigungsnachricht 
empfangen und es wird in der Multiplexerkomponente 



ASC gepruft, ob das Benutzerzertifikat sowie die digita- 
le Unterschrift korrekt sind 

Weiterhin wird von der Multiplexerkomponente ASC 
fur den Fall, daB die Oberprufung ein positives Ergebnis 
5 liefert und die empfangene Nachricht die Bestatigungs- 
nachricht war, ein erster Sitzungsschlussel unter Be- 
rucksichtigung der vereinbarten kryptographischen Al- 
gorithmen fur eine folgende Nutzdatenubertragungs- 
phase erzeugt. 

10 Aus dem ersten Sitzungsschlussel wird eine erste Sit- 
zungsschlusselnachricht gebildet und an die Benutzer- 
einheit XSi gesendet, die mindestens folgende Kompo- 
nenten aufweist: 

15 — den mit einem offentlichen Schlussel des Servers 
XSi verschlusselten ersten Sitzungsschlussel, 

— eine Spezifikation der zu verwendenden krypto- 
graphischen Verfahren, 

— eine mindestens iiber die erste Zufallszahl, die 
20 zweite Zufallszahl, den ersten Sitzungsschlussel ge- 

bildete digitale Unterschrift sowie die Spezifikation 
der zu verwendenden kryptographischen Verfah- 
ren. 

25 Wurde von der Multiplexerkomponente ASC die 
zweite Verhandlungsnachricht empfangen, und die 
Oberprufung des Benutzerzertifikats und der digitalen 
Unterschrift oder des Hash-Werts der zweiten Ver- 
handlungsnachricht hat ein positives Ergebnis ge liefert, 

30 wird in der Multiplexerkomponente ASC geprlif t, ob die 
in der zweiten Verhandlungsnachricht vorgeschlagenen 
kryptographischen Algorithmen zur Durchfiihrung der 
weiteren kryptographischen Verfahren von der Multi- 
plexerkomponente ASC unterstiitzt werden. 

35 Werden die vorgeschlagenen kryptographischen Ver- 
fahren von der Multiplexerkomponente ASC unter- 
stiitzt, wird ein erster Sitzungsschlussel unter Beruck- 
sichtigung der vereinbarten kryptographischen Algo- 
rithmen fur die folgende Nutzdateniibertragungsphase 

40 erzeugt 

Weiterhin wird, wie im vorigen beschrieben wurde, 
eine erste Sitzungsschlusselnachricht unter Venven- 
dung des ersten Sitzungsschliissels an die Multiplexer- 
komponente ASC gesendet 
45 Diese im vorigen beschriebene Vorgehensweise zum 
"Aushandeln" der zu verwendenden kryptographischen 
Verfahren wird solange wiederholt, bis sowohl die Be- 
nutzereinheit XSi als auch die Multiplexerkomponente 
ASC zuletzt vorgeschlagenen kryptographischen Ver- 
so fahren akzeptieren. 

In der Benutzereinheit XSi wird der erste Sitzungs- 
schlussel unter Verwendung eines privaten Schliissels 
der Benutzereinheit XSi ermittelt Ferner wird die digi- 
tale Unterschrift der ersten Sitzungsschlusselnachricht 
55 uberpruft 

AuBerdem wird fur den Fall, daB die Oberprufung der 
digitalen Unterschrift ein positives Ergebnis lieferte, ei- 
ne zweite Sitzungsschlusselnachricht gebildet unter 
Verwendung eines zweiten Sitzungsschliissels, der von 
60 der Benutzereinheit XSi gebildet wird 

Die zweite Sitzungsschlusselnachricht weist minde- 
stens folgende Komponenten auf: 

— den mit einem offentiichen Programmschlussel 
65 der Multiplexerkomponente ASC verschlusselten 

zweiten Sitzungsschlussel, und 

— eine mindestens iiber die erste Zufallszahl, die 
zweite Zufallszahl, den zweiten Sitzungsschlussel 
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gebildete Digitale Unterschrift oder einen uber die- 
selben Komponenten gebildeten Hash-Wert 

Von der Multiplexerkomponente ASC wird die zwei- 
te Sitzungsschlusselnachricht empfangen und der zwei- 5 
te Sitzungsschlussel ermitteit. Die digitale Unterschrift 
oder der Hash-Wert der zweiten Sitzungsschlusselnach- 
richt wird uberpriift 

Lieferte die Prufung der digitalen Unterschrift ein 
positives Ergebnis, werden die ausgetauschten Sit- 10 
zungsschlussel in der folgenden Nutzdatenubertra- 
gungsphase zur Verschlusselung der Nutzdaten ver- 
wendet Dabei verwendet jede beteiligte Instanz den 
Sitzungsschlussel, der von ihr selbst generiert wurde 
zum Senden von Nutzdaten, wahrend der empfangene 15 
Sitzungsschlussel ausschlieBlich zum Empfangen von 
Nutzdaten verwendet wird. 

Weitere kryptographische Verfahren zum Schlussel- 
austausch bzw. zur Bildung des Sitzungsschlussels fur 
die Nutzdatenverschiusselung sind im Rahmen des er- 20 
findungsgemaBen Verfahrens ohne Einschrankungen 
einsetzbar. 

Die erfindungsgemaBen Verfahren konnen sehr vor- 
teilhaft in folgendem Szenario eingesetzt werden. 

In vielen privaten Netzen werden zwischen vernetz- 25 
ten Rechnern sehr vertrauliche Informationen unterein- 
ander ausgetauscht Hierbei ist meistens das private 
Netz selbst sehr gut abgesichert gegen die AuBenwelt, 
beispielsweise durch sogenannte Firewalls [6J 

Wenn nun ein an das jeweils abgesicherte private 30 
Netz angeschlossene Rechner mit einem sich auBerhalb 
dieses Netzes, nur uber einen unsicheren Kanal erreich- 
baren Rechner kommunizieren mochte, beispielsweise 
einem nur uber das Internet IN erreichbaren Rechner, 
besteht bisher ein groBes Problem darin, daB bei dem 35 
auf [1] basierenden Client-Server- Fenster-Systemen 
keine sichere Kommunikation moglich ist 

Insbesondere ergibt sich das Problem, daB uber Fen- 
sterdienstprogramme andere .Anwendungen angegrif- 
fen werden konnen. Urn das Ausspahen interner Infor- 40 
mationen zu verhindern, ist es in Firmennetzen in der 
Regel nicht erlaubt, ein Fensterdienstprogramm auBer- 
halb des Firmennetzes zu betreiben. Diese allgemein 
ubliche Beschrankung behindert insbesondere synchro- 
ne CSCW-Systeme, die auf Application Sharing beru- 45 
hen. 

Diese Probleme sind beispielsweise in [6], [7] ausfiihr- 
lich geschildert 

Es muB sich bei diesem Problem nicht unbedingt urn 
eine uber ein lokales Netz ubergreifende Kommunika- 50 
tion handeln, sondem es kann sich beispielsweise auch 
urn ein abgesichertes Corporate Network CN handeln, 
bei dem ein Kommunikationspartner mit einem anderen 
Kommunikationspartner einer anderen Firma uber den 
Rechner beispielsweise in einem CSCW-System kom- 55 
munizieren mochte. 

Durch die erfindungsgemaBen Verfahren ist es nun- 
mehr moglich, bei Einsatzen dieser Verfahren in einem 
Firewall SCI, SC2 des lokalen Netzes bzw.des Corpora- 
te Networks CN, wobei eben der Firewall jeweils als eo 
erste Sicherungscomputereinheit SCI bzw. als zweite 
Sicherungscomputereinheit SC2 anzusehen ist (vgl 
Fig. 3). 
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Patentanspruche 

1. Verfahren zur kryptographischen Sicherung der 
rechnergestutzten digitalen Kommunikation zwi- 
schen einem Programm (P) und mindestens einer 
Benutzereinheit (XSi), 

— bei dem von dem Programm (P) eine Nach- 
richt (B) gebildet wird (601) 

— bei dem von einer Rechnereinheit, auf der 
das Programm (P) verarbeitet wird, oder von 
einer ersten Sicherungscomputereinheit (SCI) 
die Nachricht (B) mit einem Transport pro to- 
koll codiert (CB) wird (602), 

— bei dem die codierte Nachricht (CB) unter 
Verwendung des Transportprotokolls deco- 
diert (DB) wird (603), 

— bei dem die decodierte Nachricht (DB) ei- 
nem kryptographischen Verfahren (VB) unter- 
zogen wird (604), 

— bei dem die kryptographisch bearbeitete 
Nachricht (VB) mit dem Transportprotokoll 
codiert (CVB) wird (605), und 

— bei dem die codierte kryptographisch bear- 
beitete Nachricht (CVB) an die mindestens ei- 
ne Benutzereinheit (XSi) ubertragen wird 
(606) 

2. Verfahren nach Anspruch 1, 

— bei dem die codierte kryptographisch bear- 
beitete Nachricht (CVB) von der mindestens 
einen Benutzereinheit (XSi) oder von einer 
zweiten Sicherungscomputereinheit (SC2) 
empfangen wird (701), 

— bei dem unter Verwendung des Transport- 
protokolls die codierte kryptographisch bear- 
beitete Nachricht (CVB) decodiert (DVB) wird 

(702) , 

— bei dem die decodierte kryptographisch be- 
arbeitete Nachricht (DVB) einer zu dem kryp- 
tographischen Verfahren inversen kryptogra- 
phischen Bearbeitung (DEB) unterzogen wird 

(703) , 

— bei dem die invers kryptographisch bear- 
beitete Nachricht (DEB) mit dem, Transport- 
protokoll codiert (CEB) wird (704), und 

— bei dem die codierte invers kryptographisch 
bearbeitete Nachricht (CEB) unter Verwen- 
dung des Transportprotokolls decodiert wird 
(705). 



3. Verfahren nach Anspruch 1, 

— bei dem die codierte kryptographisch bear- 
beitete Nachricht (CVB) von der mindestens 
einen Benutzereinheit (XSi) empfangen wird, 

— bei dem unter Verwendung des Transport- 5 
protokoils die codierte kryptographisch bear- 
beitete Nachricht (CVB) decodiert (DVB) 
wird, und 

— bei dem die decodierte kryptographisch be- 
arbeitete Nachricht (DVB) einer zu dem kryp- 10 

. tographischen Verfahren inversen kryptogra- 
phischen Bearbeitung(DEB) unter/.ogen wird. 

4. Verfahren zur kryptographischen Sicherung der 
rechnergestutzten digitalen Kommunikation zwi- 
schen einem Programm (P) und mindestens einer 15 
Benutzereinheit (XSi), 

— bei dem von einer Benutzereinheit (XSi) 
eine Anforderung (A) gebildet wird (901 ), 

— bei dem von der Benutzereinheit (XSi) oder 
von einer zweiten Sicherungscomputereinheit 20 
(SC2) die Anforderung (A) mit einem Trans- 
portprotokoll codiert (CA) wird (902), 

— bei dem die codierte Anforderung (CA) un- 
ter Verwendung des Transportprotokolls de- 
codiert (DA) wird (903), 25 

— bei dem die decodierte Anforderung (DA) 
einem kryptographischen Verfahren (VA) un- 
terzogen wird (904), 

— bei dem die kryptographisch bearbeitete 
Anforderung (VA) mit dem Transportproto- 30 
koll codiert (CVA) wird (905), und 

— bei dem die codierte kryptographisch bear- 
beitete Anforderung (CVA) an das Programm 
(P) ubertragen wird (906). 

5. Verfahren nach Anspruch 4, 35 

— bei dem die codierte kryptographisch bear- 
beitete Anforderung (CVA) von dem Pro- 
gramm (P) oder von einer ersten Sicherungs- 
computereinheit (SC 1 ) empfangen wird ( 1 00 1 ), 

— bei dem unter Verwendung des Transport- 40 
protokoils die codierte kryptographisch bear- 
beitete Anforderung (CVA) decodiert (DVA) 
wird (1002), 

— bei dem die decodierte kryptographisch be- 
arbeitete Anforderung (DVA) einer zu dem 45 
kryptographischen Verfahren inversen kryp- 
tographischen Bearbeitung (DEA) unterzogen 
wird (1003), — bei dem die in vers kryptogra- 
phisch bearbeitete Anforderung (DEA) mit 
dem Transportprotokoll codiert (CEA) wird 50 
(1004), und 

— bei dem die codierte invers kryptographisch 
bearbeitete Anforderung (CEA) unter Ver- 
wendung des Transportprotokolls decodiert 
wird (1005). 55 

6. Verfahren nach Anspruch 4, 

— bei dem die codierte kryptographisch bear- 
beitete Anforderung (CVA) von dem Pro- 
gramm (P) empfangen wird, 

— bei dem unter Verwendung des Transport- 60 
protokoils die codierte kryptographisch bear- 
beitete Anforderung (CVA) decodiert (DVA) 
wird, und 

— bei dem die decodierte kryptographisch be- 
arbeitete Anforderung (DVA) einer zu dem 65 
kryptographischen Verfahren inversen kryp- 
tographischen Bearbeitung (DEA) unterzogen 
wird. 



7. Verfahren zur kryptographischen Sicherung der 
rechnergestutzten digitalen Kommunikation zwi- 
schen einem Programm (P) und mindestens einer 
Benutzereinheit (XSi), 

— bei dem von dem Programm (P) eine Nach- 
richt (B) gebildet wird (1 101), 

— bei dem die Nachricht (B) einem kryptogra- 
phischen Verfahren (VB) unterzogen wird 
(1102), 

— bei dem die kryptographisch bearbeitete 
Nachricht (VB) mit dem Transportprotokoll 
codiert (CVB) wird (1103), 

— bei dem die codierte kryptographisch bear- 
beitete Nachricht (CVB) an die mindestens ei- 
ne Benutzereinheit (XSi) ubertragen wird 
(1104), 

— bei dem die codierte kryptographisch bear- 
beitete Nachricht (CVB) von der mindestens 
einen Benutzereinheit (XSi) oder von einer 
zweiten Sicherungscomputereinheit (SC2) 
empfangen wird(l 105), 

— bei dem unter Verwendung des Transport- 
protokolls die codierte kryptographisch bear- 
beitete Nachricht (CVB) decodiert (DVB) wird 
(1106) 

— bei dem die decodierte kryptographisch be- 
arbeitete Nachricht (DVB) einer zu dem kryp- 
tographischen Verfahren inversen kryptogra- 
phischen Bearbeitung (DEB) unterzogen wird 
(H07), 

— bei dem die invers kryptographisch bear- 
beitete Nachricht (DEB) mit dem Transport- 
protokoll codiert (CEB) wird (1 108), und 

— bei dem die codierte invers kryptographisch 
bearbeitete Nachricht (CEB) unter Verwen- 
dung des Transportprotokolls decodiert wird 
(1109). 

8. Verfahren zur kryptographischen Sicherung der 
rechnergestutzten digitalen Kommunikation zwi- 
schen einem Programm (P) und mindestens einer 
Benutzereinheit (XSi), 

— bei dem von der mindestens einen Benut- 
zereinheit (XSi) eine Anforderung (A) gebildet 
wird(120l), 

— bei dem die decodierte Anforderung (DA) 
einem kryptographischen Verfahren (VA) un- 
terzogen wird (1202), 

— bei dem von der Benutzereinheit (XSi) oder 
von einer zweiten Sicherungscomputereinheit 
(SC2) die kryptographisch bearbeitete Anfor- 
derung (A) mit einem Transportprotokoll co- 
diert (C A) wird (1203), 

— bei dem die codierte kryptographisch bear- 
beitete Anforderung (CVA) an das Programm 
(P) ubertragen wird ( 1 204), 

— bei dem die codierte kryptographisch bear- 
beitete Anforderung (CVA) von dem Pro- 
gramm (P) oder von einer ersten Sicherungs- 
computereinheit (SCI) empfangen wird (1205), 

— bei dem unter Verwendung des Transport- 
protokolls die codierte kryptographisch bear- 
beitete Anforderung (CVA) decodiert (DVA) 
wird (1206), 

— bei dem die decodierte kryptographisch be- 
arbeitete Anforderung (DVA) einer zu dem 
kryptographischen Verfahren inversen kryp- 
tographischen Bearbeitung (DEA) unterzogen 
wird (1207), 
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- bei dem die invers kryptographisch bear- 
beitete Anforderung (DEA) mit dem Trans- 
portprotokoll codiert (CEA) wird (1208X und 

- bei dem die codierte invers kryptographisch 
bearbeitete Anforderung (CEA) unter Ver- 5 
wendung des Transportprotokolls decodiert 
wird (1209). 

9. Verfahren nach einem der Anspruche 1 bis 8, 

- bei dem die kryptographische Bearbeitung 
mindestens durch eine Verschlusselung der 10 
Anforderung (Ai) realisiert ist(81),und 

- bei dem die inverse kryptographische Bear- 
beitung mindestens durch eine Entschlussel- 
ung der Anforderung (Ai) realisiert ist. 

10. Verfahren nach einem der Anspruche 1 bis 9, 15 

- bei dem die kryptographische Bearbeitung 
mindestens durch Authentikationsmechanis- 
men fur die Anforderung (Ai) realisiert ist (82), 
und 

- bei dem die inverse kryptographische Bear- 20 
beitung mindestens durch inverse Authentika- 
tionsmechanismen fur die Anforderung (Ai) 
realisiert ist. 

1 1. Verfahren nach einem der Anspruche 1 bis 10, 

- bei dem die kryptographische Bearbeitung 25 
mindestens durch Zugriffskontrollmechanis- 
men fur die Anforderung (Ai) realisiert ist (83), 
und 

- bei dem die inverse kryptographische Bear- - 
beitung mindestens durch inverse Zugriffskon- 30 
trollmechanismen fur die Anforderung (Ai) 
realisiert ist 

12. Verfahren nach einem der Anspruche 1 bis 11, 
bei dem zu Beginn des Verfahrens eine kryptogra- 
phische Initialisierungsphase mit Bildung eines Sit- 35 
zungsschltissels fur jede Verbindung einer Benut- 
zereinheit (XSi) mit dem Programm (P) durchge- 
fuhrt wird. 
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Specification 

This invention relates to a process for the cryptographic 
securing of communication in so-called Client-Server window 
systems with an open network interface. An example of such 
Client-Server window systems is described in [1] . 

By additionally using a so-called Application Sharing 
Component, which is used to multiplex the requests of user units 
addressed to the program and to demultiplex communications from 
the program, for example, event messages, responses or error 
messages, one can achieve the common use of a Standard Single- 
User Application environments that can be located in different 
places . 

The common processing of a program is referred to as 
Application Sharing . 

But to achieve reliable communication of confidential data, 
the Client-Server window system, described in [1] , must be 
expanded by cryptographic characteristics. 

This is particularly important in communication between 
various enterprises. Here is what that means: In case of a 
communication between computers where one computer is in the 
basically secured, confidence -worthy , so-called Corporate 

1 Numbers in the margin indicate pagination in the foreign text. 
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Network of an enterprise and other computers that [are] in a 
common synchronously distributed working environment of several 
cross-linked computers in a so-called Computer System Cooperated 
Work System (CWCW systems) that implements Application Sharing, 
can be achieved only via an unsecured channel, which means that 
secure communication is no longer guaranteed. 

Such CSCW systems are based on the possibility of 
processing a standard single-user application (Standard Single 
User Application) together with other units at one particular 
point in time. 

The information exchanged between the computers can be of 
special significance, for example, it may involve confidential 
business information, design specifications, financial 
transactions or medical data that are exchanged via the 
unsecured channel . 

This is why it is necessary to ensure a certain degree of 
security also for these transactions that involve application 
data . 

In many commercial systems that are based on the Client - 
Service window system described in [1] , direct integration of 
cryptographic characteristics is not possible. 

The problem behind the invention thus is to provide a 
process for the cryptographic securing of computer-assisted 
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digital communication between a program and at least one user 
unit . 

The problem is solved by the process according to Claim 1, 
the process according to Claim 4, the process according to Claim 
7 as well as the process according to Claim 8. 

In the process according to Claim 1, the program forms a 
communication that is coded for at transport protocol. Directly 
after encoding using the transport protocol, the encoded 
communication is again decoded and the decoded communication is 
subjected to the cryptographic process. Then the request is 
again encoded with the transport protocol and is transmitted to 
at least one user unit. In this case, the program and the user 
unit can be in one or also on various computers. 

In the process according to Claim 4, one basically takes 
the same steps with the difference that this time a request is 
formed in a user unit and that the additional steps described 
above are also taken there. To complete the procedure, the 
encoded cryptographically processed request is transmitted to 
the program in this case. 

In the process according to Claim 7, one starts with the 
following situation: On the side of the program, an expansion 
of the Client-Server window system is possible by means of 
security mechanisms of the most varied kind, which will be 
described below. For this case, the above-described process 
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steps will be performed in a user unit starting with the 
formation of a communication in the program only after reception 
of the requests that were cryptographically processed in the 
inserted security layer on the side of the program. In other 
words, the inverse cryptographic processes are performed there 
in order to process the communications and this process step is 
characterized by a prior decoding with the transport protocol 
and subsequent encoding with the transport protocol. 

The process according to Claim 8 basically features the 
same process steps as the process according to Claim 7 with the 
following difference: Here a request is formulated by a user 
unit and transferred to the program. The placed where the 
individual process steps occur and the places where the process 
steps of Claim 7 are performed are simply switched around in 
this case. 

Advantageous developments of the invention-based process 
will result from the subclaims. 

It is advantageous by way of cryptographic processing to 
provide at least encoding of the request. That ensures the 
confidentiality of the exchanged data. 

It is also advantageous by way of cryptographic processing 
of the request to provide integrity and authentication 
mechanisms; this means that one can in each case guarantee then 
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that the received communication actually comes from the sender, 
who is also listed as sender in the communication. 

As a further development of the invent ion -based process, it 
is also advantageous to provide access control mechanisms as 
cryptographic processes in order thus to make sure that really 
only those requests are carried out which also have the 
entitlement for implementation. 

It is also advantageous prior to the start of the process 
during an initialization phase, for example, to exchange between 
the program and at least one user unit the cryptographic codes 
that are employed to carry out the individual cryptographic 
processes . 

The processes are used advantageously during data exchange 
between communication partners that [takes place] across the 
boundaries of a Corporate Network, which is secured by means of 
cryptographic processes via an unsecured channel in a so-called 

/2 

Firewall. '— 

By virtue of this manner of use, it is no longer necessary 
as in the past in handling an intended communication beyond 
Corporate Network boundaries to uncouple the computer used for 
the communication from the entire network of the Corporate 
Network in order thus not to endanger the entire Corporate 
Network in case of possible attacks via the unsecured 
communication channel. 
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The figures show some exemplary embodiments, which will be 
explained in greater detail below. 

Fig. 1 shows the general principle of a Client -Server 

window system; 

Fig. 2 shows the general principle of a Client -Server 
window system in a "multiuser environment" ; 

Fig. 3 shows an arrangement that describes the multiuser 
environment in a more detailed fashion; 

Fig. 4 is a basic block diagram describing the insertion of 
a security layer between the Client-Server window system and the 

transport protocol; 

Fig. 5 shows an arrangement basically illustrating how the 
invention-based process can be used in a Firewall to secure the 
communication beyond Corporate Network boundaries; 

Fig. 6 is a flow chart illustrating the process steps of 
the process according to Claim 1; 

Fig. 7 is a flow chart illustrating the process steps of 
the process according to Claim 2; 

Fig. 8 is a block diagram describing the individual 
possibilities for carrying out the security-specific processing 
of the request or the inverse security-specific processing of 
the request; 

Fig. 9 is a flow chart illustrating the individual process 
steps of the process according to Claim 4; 



Fig. 10 is a flow chart illustrating the steps of the 
process according to Claim 5; 

Fig. 11 is a flow chart illustrating the steps of the 

process according to Claim 7; 

Fig. 12 is a flow chart illustrating the steps of the 

process according to Claim 8; 

Fig. 13 is a block diagram describing the individual 
components needed to implement the process according to Claim 1 
and the communication exchange [procedure] ; 

Fig. 14 is a block diagram describing the individual 
components needed to implement the process according to Claim 4 
and the communication exchange [procedure] ; 

Fig. 15 is a block diagram describing the individual 
components needed to implement the process according to Claim 2 
and the communication exchange [procedure] ; 

Fig. 16 is a block diagram describing the individual 
components needed to implement the process according to Claim 5 
and the communication exchange [procedure] ; 

Fig. 17 is a block diagram describing the individual 
components needed to implement the process according to Claim 7 
and the communication exchange [procedure] ; 

Fig. 18 is a block diagram describing the individual 
components needed to implement the process according to Claim 8 
and the communication exchange [procedure] . 
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The invention will be explained in greater detail with 

reference to Claims 1 to 18. 

Fig. 1 shows a user environment that occurs, for example, 
in a Client-Server window system that is described in [1] . 

This arrangement displays at least the following 
components: 

- a user unit XS, hereafter also referred to as Server XS, 
which again has the following components: 

- at least one driver unit DD which facilitates coupling 
between additional peripheral components with a client XC, 
described below, 

- a display screen unit BS, 

- a keyboard TA, 

- a mouse MA., 

- the client XC that displays at least the following 
components : 

- a quantity of library routines XL as well as 

- an application ANW. 

Display screen unit BS, keyboard TA, mouse MA and possibly 
other peripheral units can be present additionally along with 
the peripheral components described above, which are coupled to 
client XC via the corresponding driver units DD. 

The quantity of the library routines XL of client XC forms 
the interface between application ANW, for example, a text 
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processing program or also a table calculation program or all 
other known applications ANW and the user unit XS. 

Together, the library routines XL as well as the 
application ANW form one program P. 

Although in this exemplary embodiment we describe in each 
case only one application ANW or one program P, one naturally 
can supply several applications ANW and thus several clients XC 
on one computer unit that performs this particular application 



ANW. 



This request, illustrated in Fig. 1, is thus only a very 
simple, basic example for the routing of the communication of a 
client XC with the server XS such as it is carried out via the 
known Client-Server window system described in [1] . 

Server XS transmits a request A to client XC. As a result, 
actions are triggered in client XC, for example, in application 
ANW. 

Request A, for example, can be an input on keyboard TA that 
via the driver units DD is "translated" into request A and is 
transmitted to client XC. 

Application ANW, for example, a text processing program or 
a calculation program, a symbol program and similar programs can 
now accept the input and, for example, include a new letter in 
the text data file. 
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To make sure that this change in the text data file can 
also be illustrated on the display screen BS in a response B, in 
this case, for example, an illustration communication, is 
transmitted to display screen unit BS by means of which a change 
in the display screen illustrated is requested. H 
One disadvantage inherent in many commercial systems that 
work according to this principle resides above all in the fact 
that a direct integration of needed security mechanisms into the 
Client-Server window system is often impossible. 

That, it so happens, would require direct interrupt into 
the interface between the library routines XL and the transport 
protocols. The latter, it just so happens, are often not 

accessible to the user. 

Fig. 6 shows a flow chart with individual process steps 
involved in the invention-based process according to Claim 1. 
The arrangement, needed to implement this process, is described 
in Fig. 13. 

Program P formulates communication B in a first step 601. 

A new communication is formed from communication B in a 
transport protocol layer TP in that communication B is 
"embedded" into the transport protocol format, in other words, 
it is coded 602, CB. 
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An overview of the various transport protocols can be found 
in [2] . The invention-based processes are independent of the 
special particular transport protocol that is being used. 

Either on the same computer unit on which program P runs or 
on a separately provided first security computer unit SCI, which 
is coupled to the computer via a secure channel, the coded 
communication CB is decoded 603, DB in the transport protocol 
layer TP that is provided there. 

The decoded communication DB is now routed to a security 
layer SL in which it is subjected 604 to various randomly 
predetermined cryptographic procedures. 

A cryptographically processed communication VB, formed by 
cryptographic processing, is now again encoded 605 in the 
transport protocol layer TP, as a result of which, a coded 
cryptographically processed communication CVB is formed. 

The coded cryptographically processed communication CVB is 
transferred in a last step 606 to the user unit XS, in other 
words, to the Server. 

The basically reverse case for request A from Fig. 1 is 
illustrated in Fig. 9 in the form of a flow chart and in Fig. 14 
in the form of a block diagram for the arrangement that is 
needed to implement the process. 

In this case, request A is formed 901 by the user unit XS . 
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Request A is returned to the transport protocol layer TP 
and it is there embedded 902 into the particular transport 
protocol format that is used. An encoded request CA, resulting 
from that, is now - either in user unit XS itself or in a 
separately provided second secure computer unit SC2 that is 
coupled with user unit XS via a secure channel - "unpacked" in 
transport protocol layer TP, in other words, it is decoded 903, 
which forms a decoded request DA. 

In security layer SL, the decoded request DA that is 
supplied to it will now be subjected 904 to the provided 
cryptographic processes that will be described below. This 
results in a cryptographically processed request VA. 

The cryptographically processed request VA again is 
supplied 905 to the transport protocol unit TP and it is encoded 
there, as a result of which, there is formed an encoded 
cryptographically processed request CVA. The encoded 
cryptographically processed request CVA is transmitted in a last 
step 906 to the program P, in other words, to the Client XC. 

A development of the process according to Claim 1 is shown 
in Fig. 7 in the form of a flow chart and the arrangement needed 
to implement this process is shown in Fig. 16. 

After the performance of the process steps shown in Fig. 6 
to the lastly formed encoded cryptographically processed 
communication CVB that is transmitted to the user unit XS, the 
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encoded cryptographically processed communication CVB is 

received 701 by the at least one user unit XS or by the second 

secure computer unit SC2 . 

Using the transport protocol employed for encoding, the 

encoded cryptographically processed communication CVB is 
"unpacked," in other words, it is decoded 702 in the transport 

protocol layer TP of the user unit or of the second security 

computer unit SC2 . 

That forms a decoded cryptographically processed 
communication DVB that is now supplied to the security layer SL, 
which is also provided on the side of the user unit XS or the 
second security computer unit SC2 . In the security layer SL, 
the decoded cryptographically processed communication DVB is 
subjected 703 to the particular inverse cryptographic processes. 
In this context, inverse means inversely with respect to the 
cryptographic processes that were applied in the security layer 
of the Client XC or of the first security computer unit SCI upon 
the decoded communication DB. 

The result of this cryptographic processing is an inversely 
cryptographically processed communication DEB, which now again 
is supplied to the transport protocol layer TB, where it is also 
again encoded 704. 



14 



The resultant encoded inversely cryptographically processed 
communication CEB is again supplied to the transport protocol 
layer TB and is decoded 705 there. 

The resultant communication is now supplied to the actual 
Server XS, in other words, to the user unit XS, and is further 
processed there. A variant of the process is of course also 
possible in terms of directly further processing the inversely 
cryptographically processed communication DEB. 

The basically identical development of the process 
according to Claim 4, that is, the same as in the previously 
described development for the process according to Claim 1, is 
illustrated in Fig. 10 along with the arrangement needed to 
implement the process according to Claim 5 shown in Fig. 17. 

In this development again, one starts with the idea that 
the process steps, described in Fig. 9 up to the encoding of the 
cryptographically processed request VA and their transmission to 
the program P, have been carried out. 

The transmitted encoded cryptographically processed 
requirement CVA is received 1001 by the program P or by the 
first security computer unit SCI. 

In a further step 1002 using the transport protocol, one 
again "unpacks" the encoded cryptographically processed request 
CVA, in other words, it is decoded in the transport protocol 

/4 

layer TP. 
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Furthermore, the resultant decoded cryptographically 
processed request DVA is subjected 1003 to the cryptographic 
processing that is inverse with respect to the employed 
cryptographic process in the security layer SL to which it was 
supplied. 

The resultant inversely cryptographically processed request 
DEA is now again coded 1004 in the transport protocol layer TP. 

Then it is again decoded 1005 in the transport protocol 
layer TP and is supplied to program P. That is where the actual 
request A is further processed. 

Again it is just as well possible directly to supply the 
decoded inversely cryptographically processed request DEA to the 
program P and to process it further there. 

Fig. 11 describes another process that is similarly based 
on the common inventive idea of the processes described above. 

This time, however, it is presumed that it is possible 
directly to insert a security layer SL between Client XC and 
transport protocol layer TP. This now no longer creates the 
need on the side of Client XC twice "to run through" the 
transport protocol layer TP. 

This is illustrated in the arrangement in Fig. 17. 
Here again, program P formulates 1101 the communication B. 
But communication B, however, this time is directly subjected 
VB, 1102 to a cryptographic process in security layer S- [sic] . 
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The resultant cryptographically processed communication VB is 
supplied to transport protocol layer TP where it is encoded 
1103 . 

The encoded cryptographically processed communication CVB 
is transferred 1104 to the user unit XS, there it is received 
1105 by user unit XS or by the second security computer unit 
SC2, it is decoded in the transport protocol layer TP that is 
provided there into the decoded cryptographically processed 

communication DVB 1106. 

The latter is supplied to security layer SL and is there 
subjected 1107 to the inverse cryptographic process or 
processes . 

In the last two steps, the inversely cryptographically 
processed communication DEB is again encoded 1108 in transport 
protocol layer TP and is decoded 1109 in a last step. 

The resultant communication B is supplied to Server XS and 

is further processed. 

Security layer SL is illustrated in Fig. 4 for the case 
where it is possible to insert the security layer SL between the 
transport layer TP and the library routines XL. 

This time, however, looking at the special example which in 
no way whatsoever restricts the general validity, unsecured 
read, write, readv, writev connect and accept communications are 
"secured" by the cryptographic process provided in security 
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layer SL. This is done by applying the provided cryptographic 
processes upon the particular communication B or request A. The 
communications that are "secured" by security layer SL are 
marked in Fig. 4 by an asterisk *. 

The described cryptographic securing of the communication 
of an application with a window system via a network, on the one 
hand, presupposes the exchange of the cryptographic codes and, 
on the other hand, is based on a reciprocal authentication of 
the two communications partners. 

For this authentication, one can advantageously employ 
asymmetrical cryptographic processes together with certificates 
that contain public codes. By suitable definition of the 
identity characteristics in the certificate, it is possible to 
identify and authenticate services such as applications or 
window service programs beyond the mere computer address in the 
network. Such identity characteristics that go beyond the 
network address for the differentiation of various application 
programs of a computer, for example, can be the name of the 
service owner on a multiuser system. 

The reciprocal authentication and the code exchange are 
carried out in an initialization phase to build up the secure 
connection. 

As a further development of the invent ion -based process, it 
is advantageous on the side of the window service program, in 



18 



.. vr . fo C arrv out an access check on 
other words, the user unit XC, to carry 

the basis o£ the authenticated identity of program P. The 
authenticated identification information can go beyond the 
computer address of program P.- therefore, an access check can 
differentiate between various programs P of a computer and can 
thus control the buildup of the connection. 

An advantageous application of the described security 
procedure can be found in the exchange of application data 
between a program P and a window service program, in other 
words, a user unit XC, where only one network connection that is 
not worthy of confidence can be switched between both of them. 

This scenario is especially important to the above- 
described CSCW systems that do the Application Sharing. Here 
the participating window service programs of the user units XC 
are often in different company networks and can exchange data 
with the application or the Application Sharing component only 

via public networks. 

Considerable security problems are connected with the 
operation of the known window system and they are described in 
[6 ] , [7] . Due to the considerable risk potential that is tied 
to the window system known from 11] , the operators of company 
networks as a rule do not allow such window service programs to 
cooperate with applications outside the company network. This 
is intended to predict interna! company information and data 
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inventories. This protection is provided by the so-called 
Firewalls at the network transition between the in-house network 
and the outside networks. By filtering data packets on the 
transport system level, those outside networks prevent external 
application programs from accessing the in-house window service 
programs . 

These customary precautions, however, prevent the use of 
synchronous CSCW systems that are based on the following: Users 
at various sites and in various companies together cooperate via 
a synchronous CWCW system and together work with application 
programs . 

On the basis of the described security process for 
application data, one can construct a program for a Firewall, 
which makes it possible to allow in-house window service 
programs securely to communicate with outside application 

programs : 

This special program is based, on the one hand, on the 
described security expansion to protect application data in 
window systems and, on the other hand, on a gating component for 
application data. The gating component can be derived directly 
from the Application Sharing Component ASC because in this case 
there is no request for multiplexing and demultiplexing. /5 
These two components (security service program and gating 
component) form a special Firewall security service program by 
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means of which it becomes possible from an external application 
program to request a specific authentication as well as to 
subject it to an access check before the gating component 
establishes the connection to the in-house window service 
program and then switches the connection through. The 
subsequent data exchange between the external application 
program and the Firewall security service program is protected 
by cryptographic mechanisms. 

By operating packet filters in the Firewall, one can force 
external application programs first of all to establish 
connection with the described security service program. 

The corresponding process, considering the "switch of 
roles" between program and user unit XS, in other words, for 
request A, is illustrated in Fig. 12 along with the arrangement 
needed for its implementation shown in Fig. 18. 

Here one naturally assumes that security layer SL can be 
inserted on the side of the user unit XS between the user unit 
XS and the transport protocol layer TP. 

On the basis of this assumption, user unit XS thus forms 
1201 the request A. This request is directly subjected 1201 to 
the cryptographic process VA in security layer SL. 

The cryptographically processed request VA is encoded 1203 
in the transport protocol layer TP and subsequently thereto the 
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encoded cryptographically processed request CVA is transmitted 

1204 to the program P. 

There it is received 1205 by program P or by the first 

security computer unit SCI. In a transport protocol- layer TP, 

which is also provided there, it is now decoded 1206 to the 

decoded cryptographically processed request DVA. 

In security layer SL to which it is supplied in an 
additional step, the decoded cryptographic request is subjected 
1207 to the inverse cryptographic process. The resultant 
inversely cryptographically processed request DEA is again 
"packed up" in the transport protocol layer TP, in other words, 

it is encoded 1208. 

The encoded inversely cryptographically processed request 
CEA is again decoded 12 09 in an additional step in transport 
protocol layer TP and the resultant request A that is now 
cryptographically "secured" is supplied to the program and is 
further used by the program P. 

Various possibilities for implementing the cryptographic 
processes to be used in security layer SL are illustrated in 
Fig. 8. 

First of all, it is possible to apply encoding processes 81 
in security layer SL. In that way, one can achieve a 
confidentiality or integrity of the exchanged communications B 
or requests A. 
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It is furthermore provided that authentication mechanisms 
82 can also be used in security layer SL. These mechanisms make 
it possible to verify identity data of the communications 
partners in the network. These authentication mechanisms have a 
special meaning in the context, for example, of the Transport 
Control Protocols (TCP) or also the User Datagramm Protocols 
(UDP) because they do not display any authentication mechanisms 
for senders and recipients. 

The implementation of access check mechanisms 83 that are 
based on the authentication processes also offers additional 
protection for the access to the window service program in a 
Client-Server window system. 

The processes described above naturally can also very 
advantageously be applied to multiuser systems. 

The way in which the Client -Server window system described 
in [1] can be expanded into a multiuser system is described, for 
example, in [3] , [4] , [5] . 

The resultant situation with an additional multiplexer 
component ASC and several user units XSi, where an index I 
definitely identifies each user unit XSi and is a natural number 
in the range from 1 to n, is illustrated in Fig. 2. 

Here, the requests Ai are in the known manner combined by 
the individual user units XSi and communication B is transmitted 
to the individual user units XSi as copies of communication Bi . 
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The invention-based process in this context naturally are 
performed for each individual connection between client XC and 

each user unit XSi . 

This "multiuser environment" is described in even greater 
detail in Fig. 3. In this practical implementation, the 
requests Ai correspond to so-called Xrequests and the 
communications Bi correspond to the so-called Xreplies, Xevents, 
Xerrors. The application ANW accesses the system resources SR. 
via the system calls SC. 

By way of a further development of the process, it is 
advantageous at the start of the process to provide for an 
initialization phase in which, for example, one performs a code 
exchange as well as a bilateral authentication between a user 
unit XS of the user units XSi and the program P. 

The most varied processes for code exchange are known in 
this case to the expert. As an example of an initialization 
phase that can be employed in the invention-based process, we 
propose the following procedure: 

The process for code exchange, described below, is 
generally carried out between client XC and a user unit XS . The 
multiplexer component ASC in this context is to be considered as 
a special component of client XC. 

Assuming that the multiplexer component ASC has an 
application certificate and that the user units, in other words, 
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the servers XSi in each case do have a user certificate which in 
each case unambiguously are associated with the user units, the 
multiplexer component ASC then generates a first random number. 

After a transport connection between the multiplexer 
component ASC and the particular server XSi has been filled up, 
the multiplexer component ASC transmits a first negotiation 
communication to the user unit, which at least displays the 
following components: / §. 

- the program certificate, 

- the first random number, 

- a first proposal for a cryptographic process that is to 
be used further on and 

- a digital signature that is formed at least via the first 
random number as well as the first proposal. 

The first negotiation communication is received by the 
particular user unit, in other words, the server XSi. 

The user unit XSi checks the program certificate for 
correctness . 

The digital signature is also checked out. 

If the check on the program certificate and the digital 
signature produces a positive result, then the user unit XSi 
further checks whether the proposed cryptographic algorithms 
that were proposed in the first negotiation communication can 
continue to be used to secure the transmission. 
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When the user unit XSi cannot support the proposed 
cryptographic algorithms, then the user unit, in other words, 
the server XSi, formulates a second proposal in a second 
proposal communication and transmits it to the multiplexer 
component ASC. The second proposal displays cryptographic 
processes that are supported by the user unit XSi. These 
[processes] are now proposed to the multiplexer component ASC as 
cryptographic processes to be employed as the procedure is 
further pursued for this logical connection between the 
multiplexer component and the user unit XSi. 

The second proposal communication has at least the 
following components: 

- the user certificate of the particular server XSi, 

- a second random number that was generated by the user 

unit XSi itself, 

- the second proposal, 

- a digital signature that in each case would be formed at 
least via the first random number, the second random number as 
well as the second proposal. 

The second proposal communication is transmitted to the 

multiplexer component ASC. 

If the cryptographic algorithms given in the first proposal 
are supported by the user unit XSi, then the user unit XSi 
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formulates a confirmation communication and sends it to the 
multiplexer component ASC . 

The confirmation communication has at least the following 

components : 

- the user certificate, 

- the second random number, 

- a positive confirmation and 

- a digital signature formed in each case at least via the 
first random number, the second random number and the positive 
confirmation. 

The confirmation communication is sent to the multiplexer 

component ASC. 

The multiplexer component ASC receives the negotiation 
communication or the confirmation communication and the 
multiplexer component ASC checks to see whether the user 
certificate as well as the digital signature are correct. 

Furthermore, if the check yields a positive result and if 
the received communication was the confirmation communication, 
the multiplexer component ASC will generate a first session 
code, considering the agreed-upon cryptographic algorithms for a 
subsequent useful data transmission phase. 

A first session code communication is formed from the first 
session code and is sent to the user unit XSi, which at least 
has the following components: 
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- the first session code that is encoded with a public code 

of the server XSi, 

- a specification of the cryptographic processes to be 

employed, 

- a digital signature that is formed at least via the first 
random number, the second random number, the first session code 
as well as the specification of the cryptographic processes to 
be employed. 

If the multiplexer component ASC received the second 
negotiation communication and if the check on the user 
certificate and the digital signature or the hash value of the 
second negotiation communication yielded a positive result, then 
the multiplexer component ASC checks to see whether the 
cryptographic algorithms proposed in the second negotiation 
communication are supported by the multiplexer component ASC for 
the implementation of additional cryptographic processes. 

When the proposed cryptographic processes are supported by 
the multiplexer component ASC, then a first session key is 
generated, considering the agreed-upon cryptographic algorithms 
for the following useful data transmission phase. 

Furthermore, as described above, a first session code 
communication is sent to the multiplexer component ASC using the 
first session code. 
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This above -described procedure for "negotiating" the 
cryptographic processes that are to be employed is repeated 
until such time as both the user unit XSi and the multiplexer 
component ASC accept the last-proposed cryptographic processes. 

In user unit XSi, the first session code is determined, 
employing a private code of the user unit XSi. Furthermore, the 
digital signature of the first session code communication is 
checked out . 

Besides, if the check of the digital signature supplies a 
positive result, a second session code communication is 
formulated, employing a second session code that is formulated 
by the user unit XSi . 

The second session code communication displays at least the 

following components: 

- the second session code encoded with a public program 
code of the multiplexer component ASC and 

- a digital signature that is formed at least via the first 
random number, the second random number, the second session code 
or a hash value formed via the same components. /7 

The multiplexer component ASC receives the second session 
code communication and determines the second session code. The 
digital signature or the hash value of the second session code 
communication is now checked out. 
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If the check on the digital signature yielded a positive 
result, then the exchange session keys are employed in the 
following useful data transmission phase for the purpose of 
encoding the useful data. Here, each participating instance 
employs the session key that it generated itself for 
transmitting useful data, while the received session key is 
employed exclusively to receive useful data. 

Other cryptographic processes for code exchange or to form 
the session code for useful data encoding can be employed in the 
context of the invention-based process without any restrictions. 

The invention-based processes can be employed very 
advantageously in the following scenario. 

Highly confidential information are exchanged between 
cross-linked computers in many private networks. Here the 
private network itself is mostly very well secured against the 
outside world, for example, by so-called Firewalls [6] . 

If a computer connected to the secured private network 
would like to communicate with a computer that can be reached 
outside that network only via an unsecured channel, for example, 
a computer that can be reached only via the Internet IN, then, 
so far, there was a big problem: No secure communication is 
possible in the Client-Server window systems based on [1] . 

In particular, one encounters the following problem: Other 
applications can be attacked via the window service program. To 
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prevent snooping on in-house information, company networks as a 
rule are not allowed to operate a window service program outside 
the company network. This generally customary restrictions, in 
particular, hinders synchronous CSCW systems that are based on 
Application Sharing. 

These problems are described in detail, for example, in 

[6], [7]. 

These problems need not necessarily involve a communication 
that overlaps a local network; instead, this, for example, can 
also involve a secure Corporate Network CN where a communication 
partner wants to communicate with another communication partner 
of another company via the computer, for example, in a CSCW 
system. 

By means of the invention-based processes, it is now 
possible when these processes are employed in a Firewall SCI, 
SC2 of the local network or of the Corporate Networks CN [sic; 
verb missing in original] , whereby precisely the Firewall in 
each case is to be considered as a first securing computer unit 
SCI or as a second securing computer unit SC2 (see Fig. 3) . 
The following publications were cited in this document: 
[1] R. Scheifler et al . , "The X Window System," ACM 
Transactions on Graphics, Vol. 5, N» 2, pp. 79 to 109, April 
1986 . 
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Claims 

1. Process for the cryptographic securing of computer- 
assisted digital communication between a program (P) and at 
least one user unit (XSi) , 

- where program (P) forms (601) a communication (B) , 
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- where a computer unit on which the program (P) is 
processed or a first securing computer unit (SCI) encodes (602) 
the communication (B) with a transport protocol (CB) , 

- where the encoded communication (CB) is decoded (603) 
using the transport protocol (DB) , 

- where the decoded communication (DB) is subjected (604) 
to a cryptographic process (VB) , 

- where the cryptographically processed communication (VB) 
is encoded (605) with the transport protocol (CVB) and 

- where the encoded cryptographically processed 
communication (CVB) is transmitted (606) to the at least one 
user unit (XSi) . 

2. Process according to Claim 1, 

- where the encoded cryptographically processed 
communication (CVB) is received (701) by the at least one user 
unit (XSi) or by a second securing computer unit (SC2) , 

- where using the transport protocol the encoded 
cryptographically processed communication (CVB) is decoded (70: 
(DVB) , 

- where the decoded cryptographically processed 
communication (DVB) is subjected (703) to a cryptographic 
processing (DEB) that is inverse with respect to the 
cryptographic process, 
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- where the inversely cryptographically processed 
communication (DEB) is encoded (704) with the transport protocol 
(CEB) , and 

- where the encoded inversely cryptographically processed 
communication (CEB) is decoded (705) using the transport 
protocol . 

3. Process according to Claim 1, /§. 

- where the encoded cryptographically processed 
communication (CVB) is received by the at least one user unit 
(XSi) , 

- where, using the transport protocol, the encoded 
cryptographically processed communication (CVB) is decoded (DVB) 
and 

- where the "decoded cryptographically processed 
communication (DVB) is subjected to a cryptographic processing 
(DEB) that is inverse with respect to the cryptographic process. 

4 . Process for the cryptographic securing of computer- 
assisted digital communication between a program (P) and at 
least one user unit (XSi) , 

- where a user unit (XSi) formulates (901) a request (A), 

- where the user unit (XSi) or a second securing computer 
unit (SC2) encodes (902) the request (A) with a transport 
protocol , 
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- where the encoded request (CA) is decoded (903) using the 
transport protocol (DA) , 

- where the decoded request (DA) is subjected (904) to a 
cryptographic process (VA) , 

- where the cryptographically processed request (VA) is 
encoded (905) with the transport protocol (CVA) and 

- where the encoded cryptographically processed request 
(CVA) is transferred (906) to the program (P) . 

5. Process according to Claim 4, 

- where the encoded cryptographically processed request 
(CVA) is received (1001) by the program (P) or by a first 
securing computer unit (SCI) , 

- where, using the transport protocol, the encoded 
cryptographically processed request (CVA) is decoded (1002) 
(DVA) / 

- where the decoded cryptographically processed request 
(DVA) is subjected (1003) to a cryptographic processing (DEA) 
that is inverse with respect to the cryptographic process - 
where the inversely cryptographically processed request (DEA) is 
encoded (1004) with the transport protocol (CEA) and 

- where the encoded inversely cryptographically processed 
request (CEA) is decoded (1005) using the transport protocol. 

6. Process according to Claim 4, 
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- where the encoded cryptographically processed request 
(CVA) is received by the program (P) , 

- where, using the transport protocol, the encoded 
cryptographically processed request (CVA) is decoded (DVA) and 

- where the decoded cryptographically processed request 
(DVA) is subjected to a cryptographic processing (DEA) that is 
inverse with respect to the cryptographic process. 

7. Process for cryptographic securing of computer-assisted 
digital communication between a program (P) and at least one 

user unit (XSi) , 

- where program (P) formulates (1101) a communication (B) , 

- where the communication (B) is subjected (1102) to a 
cryptographic process (VB) , 

- where the cryptographically processed communication (VB) 
is encoded (1103) with the transport protocol (CVB) , 

- where the encoded cryptographically processed 
communication (CVB) is transmitted (1004) to at least one user 
unit (XSi) , 

- where the encoded cryptographically processed 
communication (CVB) is received (1105) by at least one user unit 
(XSi) or of a second securing computer unit (SC2) , 

- where, using the transport protocol, the encoded 
cryptographically processed communication (CVB) is decoded 
(1106) (DVB) , 
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- where the decoded cryptographically processed 
communication (DVB) is subjected (1107) to a cryptographic 
processing (DEB) that is inverse with respect to the. 
cryptographic process, 

- where the inversely cryptographically processed 
communication (DEB) is encoded (1108) using the transport 

protocol (CEB) and 

- where the encoded inversely cryptographically processed 
communication (CEB) is decoded (1109) using the transport 
protocol . 

8. Process for the cryptographic securing of computer- 
assisted digital communication between a program (P) and at 
least one user unit (XSi) , 

- where at least one user unit (XSi) formulates (1201) a 

request (A) , 

- where the decoded request (DAO is subjected (1202) to a 
cryptographic process (VA) , 

- where the user unit (XSi) or a second securing computer 
unit (SC2) encodes (12 03) the cryptographically processed 
request (A) with a transport protocol (CA) , 

- where the encoded cryptographically processed request 
(CVA) is transferred (1204) to the program (P) , 
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- where the encoded cryptographically processed request 
(CVA) is received (1205) by the program (P) or by a first 
securing computer unit (SCI) , 

- where, using the transport protocol, the encoded 
cryptographically processed request (CVA) is decoded (1206) 
(DVA) , 

- where the decoded cryptographically processed request 
(DVA) is subjected (1207) to a cryptographic processing (DEA) 
that is inverse with respect to the cryptographic process, 

- where the inversely cryptographically processed request 
(DEA) is encoded (12 08) with the transport protocol (CEA) and /9 

- where the encoded inversely cryptographically processed 
request (CEA) is decoded (120 9) using the transport protocol. 

9. Process according to one of Claims 1 to 8, 

- where the cryptographic processing is performed (81) at 
least by one encoding of the request (Ai) and 

- where the inverse cryptographic processing is carried out 
at least by one decoding of the request (Ai) . 

10. Process according to one of Claims 1 to 9, 

- where the cryptographic processing is carried out (82) at 
least by means of authentication mechanisms for the request (Ai) 
and 
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- where the inverse cryptographic processing is carried out 
at least by inverse authentication mechanisms for the request 
(Ai) . 

11. Process according to one of Claims 1 to 10, 

- where the cryptographic processing is carried out (83) at 
least by access control mechanisms for request (Ai) and 

- where the inverse cryptographic processing is carried out 
at least by inverse access control mechanisms for request (Ai) . 

12. Process according to one of Claims 1 to 11,. where at 
the start of the process, a cryptographic initialization phase 
with formation of a session code is performed for each 
connection of a user unit (XSi) with the program (P) . 

13 pages of drawings. 
[Please insert Fig. 6] . 

[Key: 601) Communication B is formulated by program P; 602) 
Communication is encoded in transport protocol layer TP; 603) 
Communication is decoded in transport protocol layer TP; 604) 
Communication is subjected to cryptographic processes; 605) 
Communication is encoded in transport protocol layer TP; 606) 
Encoded communication is transferred to user unit XS] . 
[Please insert Fig. 8] . 

[Key: 80) Cryptographic process in security layer SL; 81) 
Encoding; 82) Authentication mechanisms; 83) Access control 
mechanisms] . 
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[Please insert Fig. 7] . 

[Key: 601) Communication B is formulated by program P; 602) 
Communication is encoded in transport protocol layer TP; 603) 
Communication is decoded in transport protocol layer TP; 604) 
Communication is subjected to cryptographic processes; 605) 
Communication is encoded in transport protocol layer TP; 606) 
Encoded communication is transferred to user unit XS; 701) 
Encoded communication is received by user unit XS; 702) Received 
communication is decoded in transport layer TP; 703) Decoded 
communication is processed in an inversely cryptographic manner 
in security layer SL; 704) Inversely processed communication is 
encoded in transport layer TP; 705) Encoded communication is 
decoded in transport layer TP] . 
[Please insert Fig. 9] . 

[Key: 901) Request A is formulated by user unit XS; 902) Request 
A is encoded in transport protocol layer TP; 903) Request A is 
decoded in transport protocol layer TP; 904) Request A is 
subjected to cryptographic processes; 905) Request A is encoded 
in transport protocol layer TP; 906) Encoded request is 
transferred to program P] . 
[Please insert Fig. 10] . 

[Key: 901) Request A is formulated by user unit XS;902) Request 
A is encoded in transport protocol layer TP; 903) Request A is 
decoded in transport protocol layer TP; 904) Request A is 
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subjected to cryptographic processes; 905) Request A is encoded 
in transport protocol layer TP; 906) Encoded request A is 
transferred to program P; 1001) Encoded request A is received by 
program P; 1002) Received request A is decoded in transport 
layer TP; 1003) Decoded request A is processed in an inversely 
cryptographic manner in security layer SL; 1004) Inversely 
processed request A is encoded in transport layer TP; 1005) 
Encoded request A is decoded in transport layer TP] . 
[Please insert Fig. 11] . 

[Key: 1101) Communication B is formulated by program P; 1102) 
Communication B is subjected to cryptographic processed; 1103) 
Communication B is encoded in transport protocol layer TP; 1104) 
Encoded communication B is transferred to user unit XS; 1105) 
Encoded communication B is received by user unit XS; 1106) 
Received communication B is decoded in transport layer TP; 1107) 
Decoded communication B is processed in an inversely 
cryptographic manner in security layer SL; 1108) Communication B 
is encoded in transport protocol layer TP; 1109) Communication B 
is decoded in transport protocol layer TP] . 
[Please insert Fig. 12]. 

[Key: 1201) Request A is formulated by user unit XS; 1202) 
Request A is subjected to cryptographic processed; 1203) Request 
A is encoded in transport protocol layer TP; 12 04) Encoded 
request A is transferred to program P; 1205) Encoded request A 
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is received by program P; 1206) Received request A is decoded in 
transport layer TP; 1207) Decoded request A is processed in an 
inversely cryptographic manner in security layer SL; 1208) 
Request A is encoded in transport protocol layer TP; 1209) 
Request A is decoded in transport protocol layer TP] . 
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